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flO We have designed Kthcrnct-based workstations that support clusters or grapmcal or conventional 
Aa * terminals. This terminal system gives users the capability to communicate with any host computer 

^-'^ on the Stanford University Network (SUN), which is currendy being installed. 

Hie workstation provides up to 8 high-resolution grapiiical (bit-map) displays with 1280X819 pixels, •ffi.x^^ »k 
or up to 32 medium-resolution channels with 640X409 pixels. Ivich station is controlled by a 16-bit ' "', 

microprocessor (an MC68000) that emulates standard tcmiinals, such as Datamedias. and supports a 
network graphics protocol. 

The same basic hardware can also be configured to be a ASCII tennin;il/dial-up line concentrator, 
an Ethernet gateway, or a special device controller (e.g. for laser printers or disks). I>y adding 
memory, the hardware provides growth into a powerful personal computer system, suited for design 
automation (VLSI), advaticed text processing (CRl'F.X), a nd odier applications dcmandine dedicated 
computing power and high-resolution grapn.es. ^'^^^.^ .^.^^^ ^^^ -^W u^ ^...^^f- 

A hardware and software prototype is scheduled for July I, 1980. We plan to fabricate a small batch 
of workstations over the simimer to support the VLSI design automation project. The p.ross cost of a 
station without displays is estimated to be $8000. A dditional display chaiuicls are estimated to cost 
$500 for a low-resolution display and $2000"V()r a high-resoiution display (excluding keyboards and 
monitors). Thus the gross cost of a terminal Bystcm with 16 lov/-rcsolulion displays is estimated to 
be SI GOO per user. / 
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1. Introduction 

In the near future all major campus-wide computing resources will be connected by an Ethernet 
communication system. This network will provide us with an unprecedented level of system 
integration and thus will be extremely valuable to the entire user community. 

The Ethernet f Metcalfel is a bit-serial, broadcast, multi-drop, packet switching network that allows 
up to 256 stations to be connected via a single coaxial cable, up to I km long, by simply tapping the 
wire. Access arbitration is achieved by deferring a transmission until the channel is idle, aborting a 
transmission if a collision occurs and retransmitting after a random interval. 

Tiie main advantage of the Ethernet is tl\at it allows a large number of users and servers to 
communicate over a single channel at high speed. Bsscntially, the network offers tlic same 
communication mechanisms as a conventional time-sharing system. Computer mail and messages 
can be exchanged over the network, shared data bases can be kept at centralized disk-servers, and 
unique hardware devices such as laser-printers can be shared among their users. The Ethernet has a 
bandwidth of 3 Mbit/sec that allows to support all these services. 

'ITiis network technology together with the advance of semiconductor technology is fundamentally 
changing the nature of computing facilities. It is ba-oming economically and organizationaly 
advantageous to distribute computing power. High-end microcomputers of today have equal 
^ performance to small main-frames of the past, and it is becoming practical to dedicate such systems 

'i for a single or a tew users or for a given task. 'Hie availability of localized computing power is 

critically important for three purposes: 



V 



1) Interactive applications, such as program development or VLSI design, wliere the productivity 
of a researcher greatly depends on the response time of the system. 

2) Compute-bound applications, such as simulations or Al programs, where the cycles provided 
by a powerful personal machine exceed those of a typical time-shared environment. 



i 

t J Z ^^ High -speed device applications, such as raster-scan graphics, laser-printers, and audio, with 

i o \ processing and latency demands that cannot be accomodated in time-shared systems. 

In addition, a distributed system is inherently more reliable than a centrali/.ed one. 

'i'iiese considerations arc now widely recognized and have been explored in a number of existing or 
proposed machines, such as tiie Alto [Thackcr], Dorado [McDinie!]. I.isp-Macliinc[GreenLlatt], Nu- 
Computer system [Ward], PERQ (Rosen], and SPICH fNcwci!|. The approach we are proposing is 
most similar to the MIT Nu system, in that we desire a llexible solution for our immediate needs 
that will be available as soon as possible, utilizing sUmdard, olT-thc-shcIf LSI technology. We are 
currently less concerned about obtaining a very high-performance personal computer, such as a 
Dorado. Rather we sec our system evolve naturally towards higher performance with the progress of 
VLSI semiconductor technology. 

Our most immediate need is a low-cost, clustered terminal system, and a personal computer system 
with high-resolution graphics for design automation and advanced text processing. In addition, our 
hardware design can be configured as an Ethernet terminal concentrater and as an Ethernet 
gateway. A plan to build this hardware and the associated software is the core of this report. 
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l.l. Current State of tiic SUN Ethernet 

Currently, all the Xerox equipment (16 Altos, the Dover printer, and the IFS file server) and the 
VLSI VAX arc fully functional Ethernet devices. The Sau. computer is electrically connected through 
the front-end PDP-11, but the device driver for the Ethernet interface needs yet to be written. TTie 
other machines are awaiting the fabrication of our Ethernet interface boards. These interfaces will 
connect Score via the MassBus, the IBM 4331 via a Serics/1 machine, and odier equipment, such 
as the TI-990 machines, via their own I/O busses or the IEEE 488 sUindard bus. 



Ether Net 



ARPANET 



Alto 



File Server 



Total: 16 



Alto 



Alto — r — ^ — p — ■' 



(Lassen) 



Alto 



DOVER 

(Tahoe) 



11/40 



SAIL 

1080 



11/45 



.^.iK'iy.-j 



SCORE 
2060 



Terminal 
Clusters 



VLSI 
VAX1 



(proposed) 





VLSI 




VAX2 








IBM 
4331 










CArltf^ct^'t ■ 









(Arrival April 1980) 



Figure 1: Status of SUNet March 1980 



<SUN>proposal.lig1 .sil 



A Terminal System for the Stanford University Network 



1.2. Plans for a Canipus-Widc Ethernet l-«^lr$ «Lo »i* -prv TkJ 

The current schedule for the installation of Ethernet cable calls for three phases: 

Phase 1: Mai^arct Jacks Hall. This phase has been completed. 

Phase 2: A "backbone" cable will run from the North corner of the main Quadrangle along Via 
CrespL From this cable, "spurs" with Ethernet repeaters will connect Pine Hall, the 
Center for Integrated Systems Annex, the Electronics Research Laboratory, the Applied 
Electronics Laboratory, the Durand building, and the Tcrman building. Contractors arc 
currently working on this phase. This phase is scheduled for completion by May 1, 1980. 

Phase 3: The "backbone" cable will be connected to the Medical Center Facility (SuMEX), the 
Graduate School of Business, die Center for Information Technology in Foreythe Hall, 
and die Lots computer in the Ci-Ras building. Sumi:x could possibly be connected 
during Phase 2 via Pine Hall. Phase 3 is scheduled for fiscal 198L 







Terman 




R 




CERAS 
(LOTS) 








m 1 




ff 










1 




Durand 
(ISL) 




R 


4 




1 



<sun>propo$al.fig2.9il 





Via Crespl 




CIS 



Repeater 
Gateway 



A Terminal System for the Stanford University Network 



2. Tlie Architecture of the SUN Station 

The main goals of die hardware designed are to provide a flexible and powerful human interface, to 
support the Ethernet communication architecture, and to provide localized processing power. We 
shall first discuss the interactive input/output and then briefly describe the actual hardware 
components and the suggested configurations. 

2.1. Interactive Output 

We plan to use bit-map raster-scan graphics displays as output devices that provide a choice of 
high-resolution or medium-resolution monochrome, greyscalc, or color displays. 

A raster display is one of the most general output device available today. It can represent characters 
of arbitrary size and style, vectors and curves, solid and grey areas, and it can simulate half-tone 
images [Thacker, Newman-SproullJ. A frame buffer display is also very economical: given current 
dynamic memory costs of less than 0.05 cents per bit, a single-bit per pixel frame buffer is about as 
expensive as the attached video monitor, be it a low-, medium, or high-resolution display. As the 
price of dynamic RAMs continues to decline, we expect to see incrctisingly large frame butters in 
the future, providing enhanced resolution, grey-scale, and color. 

Our design provides two kinds of display resolution: 

High-resolution displays with 1024X1024 pixels (or 1280X819), and 
Medium-resolution displays with 512X512 pixels (or 640X409). 

For both resolutions there is the option of using multiple bits per pixel which can be mapped into 

colors or grey-scale through a look-up table. 

The high-resolution display is the configuration of choice for design automation, text processing, 
and advanced program interfaces. A high-resolution frame buffer contains four times as many pixels 
as a Data-Disc display, two times as many pixels as an Alto display. It can either display a high- 
quality image of a standard sheet of paper in "portrait" mode, or two sheets side by side in 
"landscape" mode. The medium-resolution format is comparable to tlie current Data-Disc displays 
and will probably be used in "landscape" mode. It provides compatibility with low-cost video 
monitors, including our current Ball monitors, and is suited for economical color and grey-scale 
systems. 

Besides the resolution of a raster display, its update speed is a crucial factor. Our goal was to change 
a complete high-resolution frame buffer without a noticablc delay. Specifically, the entire screen 
should be scrolled within 64 milliseconds. Tlie number of bits that must be accessed, shifted, 
masked, and modified in that time requires significant pnKCSsing power. We have developed a 
novel frame buffer organization wliich reduces processing demands to a level where a single 16-bit 
microcomputer can serve a number of frame buffcre. In brief, a small amount of special hardware 
implements a "RastcrOp" rectangle manipulation function [Ncwman-Sproull] that makes it possible 
to modify rasters in die frame buffer at full memory bandwidth (32 Mbit/sec) without processor 
intervention. The host processor only needs to setup the source and destination location, the height 
and width of the rectangle, and the bit-operation desired. F,xcluding this overhead, a 16X16 
character can be put into die frame buffer in 16 microseconds, and a 1024X1024 RastcrOp takes 64 
milliseconds. 
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2.2 Interactive Input 



) We plan to use unencodcd keyboards in which any number of keys can be depressed 

^ simultaneously to represent desired functions. This provides edit keys, M eta keys, or any number 

JL of shift keys desired. ' 

The issue of a "standard" keyboard is a difficult one. Most users can do with an Alto-like keyboard, 
maybe with additional programmable keys that can be redefined. The concept of an unencoded 
keyboard allows the internal microproce^or to simulate any desired keyboard to the host computer, 
but changing tiie key tops won't be as easy. 

"V ^ For design automation and other graphics applications, a pointing device, such as a mouse or a 

•«♦. ^ tablet, is essential. Unfortunately, pointing devices cost about $500 and arc probably too expensive 

V - for use in the clustered terminal configuration. 

W — 23 Hardware Components 

h V '" ^^^^' ^^^^ ^"^^ ^^^^^ "^''''" hardware components: a self-contained Ethernet interface, an 
MC68000 microcomputer system with serial and parallel ports, and a high-performance graphics 
subsystem. These components plug into an industry standard backplane, the Intel Multibus. 



The Ethernet interface was designed to work with any host computer without making short latency 
or significant service demands. It is a full-duplex interface incorporating 16-word buffers for 
receiving and transmitting, collision filtering, programmable address filtering, hardware CRC 
generation and checking, and automatic retransmission. The address filter is specified as a bit-vector, 
which allows it to respond to any set of the 256 Ethernet addresses. Extensive self-test and 
diagnostic facilities are provided. 

The MC68000 microcomputer system acts as the main controller of the station, handling the 
lUhcrnct communication and serving all die atuiched devices. It is a standard single-board computer 
with 64 kbytes of dynamic memory, two serial interfaces (for keyboards and tablets) and two 
parallel ports (for special devices such as laser printers). The design is optimized for speed and 
includes no memory management, which we felt not to be critical for the initial applications. We arc 
also designing a virtual memory microcomputer system with a dual 68000 processor which is 
discussed in [BaskettJ. 

The graphics subsystem consists of two modules, a graphics controller |)crforming the raster 
operation and generating the sync signals, and a frame buffer module containing 1024X1024 bits 
which can be reconfigured into four channels of 512X512. Up to eight frame buffers can share one 
graphics controller module. For example, a display system with 16 medium resolution channels 
needs one graphics controller and four frame buffer modules. The frame buffcre support refresh 
rates up to 64 Mbit/sec. making them compatible with practically all kinds of video monitors, 
interlaced and non-interlaced, color or monochrome. 

All the hardware modules described plug into the Intel Multibus backplane. The Multibus is 
currently being standardized by the IEEE as the 7% Bus. It is an asynchronous bus with 16 data 
and 20 address lines, supporting transfers at a rate of up to 5 MHz. There is a second, non- 
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dedicated 60-pin backplane connector for intermodule communication. This connector is utilized in 
tlic graphics subsystem and we intend to use it as a future high-speed memory bus. Standard 
Multibus boards measure 12 by 6.75 inches and hold about 100 16-pin packages. The Multibus was 
selected over many alternative busses considered because of its performance, its board-size, and its 
wide acceptance in the marketplace. There are more than 50 suppliers of Multibus compatible 
components, ranging from bubble memory to speech recognition subsystems. This supplier base is 
an advantage when we need disk controllers or other I/O devices. 

All hardware was designed with the SUDS design automation system. Most of the design was 
initially expressed in a graphical macro language similar to Scald, but more geared towards 
efficient small-scale design. SUDS produces the wirclists for building wirewrap prototypes, and we 
plan to use SUDS for laying out the PC boards for the pilot production run. 

2.4 Configuration of ihc Ethernet Stations 

The following physical constraints apply to all configurations. 
Maximum length from Kthcrnct Transceiver to Station: 40 feet 
Maximum length from Station to Video Monitors: 150 feet 

Physical size of terminal configuration: 20"xl2"xl5" (w,h,d) 

Power consumption of 16-channel station (cxcl. monitors): 300 Watt, 110 Volt 

The Terminal Cluster configuration shown has 16 medium-resolution display channels. Since a 
station supports up to eight frame buffers, a maximum of 8 high-resolution or 32 medium-resolution 
displays are possible, as long as all displays have the same resolution. Because of wiring constraints, 
it is probably best if the station is located in the same room or nearby. 

The Kthcrnet TIP configuration can be used where many conventional tcnninals are currently 
located, such as in KRL or Tcrman. One IIP can also replace the current Arpanet TIP or tlic dial- 
up lines to ScORii or Sail. An Ethernet TIP provides a central place for dial-up access to all 
machines from home terminals, without the expense of adding line multiplexer and telephone 
equipment to machines like the VAXes and the IBM 4331. 

The Kthernet Gateway is simply a dedicated station with two I-lthcrnct interfaces. Similarly, a 
printing server is a dedicated station with device specific interfaces. The department-wide utility of 
hardcopy devices coupled with the modest cost of tlie Hthcrnct station makes them especially 
attractive candidates for Ethernet devices. 

The CRTiiX/VLSl workstadon is a sLidon with a high-resolution display, keyboard, and tablet. For 
VLSI design, we also want color graphics capabilities. When tiie hardware becomes available, we 
plan to use the virtual 68000 system with signifcant amounts of primary memory and a Manciicster 
Disk for secondary storage. 
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3. Software Architecture a^>^n,u^ -4 <*-<-. 

Wc intend to use the Xerox Pup (Parc Universal P«r^/.rt nrrhit(yM.rr» for Ethernet communication. 
Pup has been used inside Xerox since 1976 and is the basis for Uicir internetwork software and 
hardware designs IBoggsJ. The fundamental abstraction of Pup communication is an end-to-end 
media-mdcpendent mternetwork datagram, hi this case, the datagram takes the form of a single 
packet traversing the network. Higher levels of amctionality arc achieved by protocols that are 
stricUy a matter of agreement among the communicating end processes. Thus, the Pup architecture 
is idcaly suited for a dynamically changing environment. Given the research nature of our 
department, there is a great advantage in providing an expandable network architccturc that will 
provide cffjcicnt interaction among users. 

rttM-AA-H Network resources arc best viewed as User and Server processes. The Dovt-R laser printer, fo r 

X^iUn-A example, is a printing server diat can respond to requests from any arbitrary host that implements 

-w- pr"U»»*r the corresponding user process. This distinction allows a resource to function as an independent 

x) u4-c^ *^"^'*^ °" ^^ network, not directly tied to a particular mainframe or its operating system. The effort 

^ required in providing a new resource to a host is greatly simplified because the server process 
presents a high-level interface to the network. For example, the 11ovi:r printing service was added 

• K^ ^" ^^'^ ^^^ machine over a weekend by simply installing the proper user-mode software to generate 

*" Pups on the Ethernet connection. 

(i A*-tvt-%v+^' '^ important to note that some local processing element must exist between every independent 
resource scr\'cr and the Ethernet. Xerox has used the Alto minicomputer for this purpose. The 
Dovr.R printer and IPS file server each have their own Alto to handle service requests from the 
"^^^^'■'^- In our own environmen t, it is unacccntahlc m use Altos as server machines (we can' t 
afford them). Although most of the departmental peripherals use an existing host machine as an 
Interface, there is a critical need for a low-cost processing clement to interface new devices that 
provide network services. Ihe SUN terminal system can be easily reconfigured to implement a 
variety of servers. 

For the display stations, only the basic Pup Telnet protcKols need be implemented on the 
worksuition's MC68000 processor. Ihc SUN terminals could then be programmed to emulate 
currently available terminals, such as Datamcdias. Tclcrays. I'cktronix 4014 graphics terminals, or HI 
_di^lays. This would allow compatibility with the extensive software on existing host machines, an 
important consideration. 

Development of protocols and interfaces to our current operating systems is progressing in parallel 
with the construcdon of the hardware. The implementation of the Pup software is designed to be 
portable to several machines besides the SUN tcnninal. In particular, software for the SUN 
terminal can be partially derived from other implementations of the Pup pjickagc (eg, the Vax 
project described below). 

Specifically, Uiere are five levels of software than must be implemented (see figure 5). The lowest 
level (Pup level 0) controls the Ethernet interface board. Altliough Jlic Hthernct interface described 
in this proposal provides a "standard" for Etlicrnct interfacing, there arc still snuill implementation 
differences between hosts, l-or example, the interface board is a memory bus device on Sail, but a 
^^^ r<-^ MassHus device on ScORi; and the Vax . The level software must deal with each host's I/O 
mechanisms. This component of the software is tlie simplest and will require one man-week per 
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host to write on systems with simple 1/0 mechanisms like Unix and SUN, 

Level 1 ftmctions provide a uniform interfecc to the Pup world. PuP packets arc filtered and 
routed at this level. Most of the level 1 functions deal with gateway routing, which need only be 
implemented on gateway machines. Without gateway routing level I should require two man-week 
to implement Software for gateway machines will require an additional three man-weeks. 

Level 2 providis three protocol interfaces, llie Rendezvous & Termination Protocol (RTP) initiates, 
manages, and terminates connections between hosts. Simple file transfers and Dover spooling 
requests use the Easy File Transfer Protocol (EFrP). More complex functions such as Telnet and 
FFP require the Byte Stream Protocol (BSP). We have many implementation examples of this 
software. The Alto software for these protocols is written in both BCPL and Mesa. Versions of 
EFTP exist in the C language under Unix and in assembler code for Pdp-IIs. There is an ongoing 
project between Stanford and CMU to implement all four Pup levels in C under Unix. This 
software, along with MIT's C compiler for the MC68000, can also be used by the display station. 
In addition, we are exchanging additional software with CMU, MIT, and Berkeley on a regular 
basis. Stanford has developed software to print TeX. XGP, and Troff files on the Dover. CMU 
and MIT are working on Pup packages and printing software. Accordingly, level 2 ftmctions can be 
implemented in three man-weeks. 

Level 3 contains the user and server processes. They are: FfP User/Server for exchanging files. 
Telnet User/Server to allow remote logins between hosts, and an EmPrcss style printing program 
for the DOVFR. F-TP and Telnet require RTP and BSP from level 2, while BmPress needs only 
Hl'TP. The implementation times vary depending on the requirements of the host machine. Level 
3 Telnet can be written in three man-weeks. 

Level 4 is made up of specific terminal emulators and display packages. We can lessen the current 
terminal shortage by emulating existing temiinals such as the DataMcdia and Tclcray. DataDisks 
and even HI displays could be emulated (a real concern given the condition of the current 
equipment). 



J j \ SUN Telnet, together with Pup levels 0, I, 2, and an appropriate emulator will require 10 man- 
q* ( weeks of implementation time. More sophisticated applications, such as a gateway or Ether TIP, 
"^ ' will require other level 3 components. Notice that once levels 0, 1, and 2 have been defined, 
additional functions are only a matter of writting die level 3 user and/or server programs. 

The Telnet software devetopement schedule is shown in figure 6. It is calibrated in weeks, 
beginning April 1. Tliese predictions refiect our best estimates given die limited manpower 
involved. F-ssendally there is one person writting the Unix/SUN software and one person doing the 
SAIL Telnet side. Additional help is expected in writing the terminal emulators. This schedule will 
be somewhat shortened if we can use the CMU level I and level 2 I'UP package they are 
developing. Actual results are expected in early June provided the prototype hardware is ready. 
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